Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BIOS Partition disk is not created in AL2 micro instances. #31

Open
ramzcode opened this issue Nov 27, 2023 · 5 comments
Open

BIOS Partition disk is not created in AL2 micro instances. #31

ramzcode opened this issue Nov 27, 2023 · 5 comments

Comments

@ramzcode
Copy link

fidisk and cfdisk can list the partion table properly but the lsblk won't list all the partitions, underlying was the /dev/xvda128 itself not created.

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk
└─xvda1 202:1 0 8G 0 part /

Disk /dev/xvda: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 84B5F398-58C6-4F8A-9DB3-02258ADEBC84

Device Start End Sectors Size Type
/dev/xvda1 4096 16777182 16773087 8G Linux filesystem
/dev/xvda128 2048 4095 2048 1M BIOS boot

Partition table entries are not in disk order.

Looks like the Udev rules needs attention, not sure what should be done, please suggest.

@ozbenh
Copy link

ozbenh commented Nov 28, 2023

This is interesting. It works fine on Nitro instances (nvme instead of xvda) and works fine with AL2023. The failure mode appears specific to AL2 with Xen. It also appears to work if I install kernel-5.15 extra in AL2. I wonder if this is an issue with the xen block driver on earlier kernels

The partitions being in the wrong order is actually intentional. For historical reasons, a lot of things out there assume root to be partition 1 on Amazon Linux, but since it needs to be resized at boot, it has to be at the end.

@ramzcode
Copy link
Author

@ozbenh Thank you for your updates, like you stated does updating the kernel will help overcome this on AL2 based on Xen. Also is it really possible to identify the exact underlying problem if it is specific to Xen block driver on the older kernels.

Updating the kernel is not a good idea for our case but patching the specific component would help us a lot.

Please advise.

@ramzcode
Copy link
Author

Update: Updating the kernel to 5.15 via Amazon extras did work, but need to find the underlying code that actually resolves the problem as upgrading the kernel is not a good choice for my environment.

@ozbenh
Copy link

ozbenh commented Nov 28, 2023

I think the fix is actually a patch I wrote and that never made it back to 5.10 for some reasons :-) I'll chase this up

@ozbenh
Copy link

ozbenh commented Nov 28, 2023

So it's about support for >16 minors in xen-blkfront. Upstream was fixed in 5.17 accross all block devices, I put a patch in for xen-blkfront in our 5.15 (originally targetting AL2022 which became 2023) but we thought at the time to preserve the old AL2 behaviour as it had always been "broken" that way. We'll do some tests and see if we can backport further

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants