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

initoverlayfs is failing to boot after install on c9s #29

Open
Yarboa opened this issue Nov 30, 2023 · 6 comments
Open

initoverlayfs is failing to boot after install on c9s #29

Yarboa opened this issue Nov 30, 2023 · 6 comments

Comments

@Yarboa
Copy link
Collaborator

Yarboa commented Nov 30, 2023

Working on this minimal packit test #28, seems that fedora is working with initoverlayfs,
but c9s machine fails to boot.

distro: CentOS Stream 9�[0m
kernel: 5.14.0-388.el9.x86_64�[0m

https://github.com/containers/initoverlayfs/pull/28/checks?check_run_id=19189680972

Need to debug manually for more details

@ericcurtin
Copy link
Collaborator

The zero logs from the boot may make this difficult but lets see, I may have a fix that works regardless

@Yarboa
Copy link
Collaborator Author

Yarboa commented Dec 3, 2023

@ecurtin Adding logs
https://pastebin.com/c4nL16WJ
line #573

initoverlay-install output
backup
https://paste.centos.org/view/b2678437

@Yarboa
Copy link
Collaborator Author

Yarboa commented Dec 4, 2023

Will propose different PR for c9s

Do not forget to add this one
#28 (comment)

@ecurtin
Copy link

ecurtin commented Dec 4, 2023

@Yarboa Think you meant to tag @ericcurtin , unless you really want this random ML Ops Engineer to parachute in from deep space and have opinions about C.

@ericcurtin
Copy link
Collaborator

Sorry @ecurtin ecurtin is my username on many other things 😄

@Yarboa
Copy link
Collaborator Author

Yarboa commented Dec 5, 2023

@ericcurtin Anyway Attaching this Log
It seems that first init, does not read storage properly
https://pastebin.com/jn8gU0Y8

With the following error, I could not point on a difference between c9s and fedora related to this ?
https://github.com/containers/initoverlayfs/blob/main/storage-init.c#L594

[    1.148667] storage-init: bootfs: {"", "bootfs "}, bootfstype: {"ext4", "bootfstype ext4"}, fs: {"(null)", "(null)"}, fstype: {"(null)", "(null)"}, udev_trigger: {"udevadm trigger --type=devices --action=add --subsystem-match=module --subsystem-match=block --subsystem-match=virtio --subsystem-match=pci --subsystem-match=nvme --subsystem-match=mmc --subsystem-match=mmc_host --subsystem-match=platform", "udev_trigger udevadm trigger --type=devices --action=add --subsystem-match=module --subsystem-match=block --subsystem-match=virtio --subsystem-match=pci --subsystem-match=nvme --subsystem-match=mmc --subsystem-match=mmc_host --subsystem-match=platform"}, udev_trigger_generic: {"udevadm trigger --type=devices --action=add", "udev_trigger_generic udevadm trigger --type=devices --action=add"}
Starting systemd-udevd version 252-18.el9
[    1.157468] storage-init: fork_execvp_no_wait(0x17c2880)
[    1.157649] storage-init: forked 209 fork_execvp_no_wait
[    1.157652] storage-init: c->bootfs.val.c_str string is ""
[    1.160622] loop: module loaded
[    1.171546] storage-init: fork_execlp_no_wait("udevadm")
[    1.171598] storage-init: forked 214 fork_execlp_no_wait
Device path cannot contain "..".
[    1.188393] storage-init: optimized udev trigger failed, fall back to generic: 1 && 1
[    1.188400] storage-init: fork_execvp_no_wait(0x17c29c0)
[    1.188474] storage-init: forked 225 fork_execvp_no_wait
[    1.199644] virtio_blk virtio2: 2/0/0 default/read/poll queues
[    1.201613] virtio_blk virtio2: [vda] 20971520 512-byte logical blocks (10.7 GB/10.0 GiB)
[    1.206224]  vda: vda1 vda2 vda3
[    1.230533] storage-init: fork_execlp("udevadm")
Device path cannot contain "..".

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

3 participants