Udev on a live CD system does not appear to populate /dev

Hi All,

I'm currently looking at using udev for a live cd environment built with buildroot, and I'm having trouble getting udev to pick up the machine's devices.

I have some questions and some details that will (hopefully) help identify my problem

Firstly, my kernel is configured to use devtmpfs:

681:CONFIG_DEVTMPFS=y
682:CONFIG_DEVTMPFS_MOUNT=y

so as I understand it, /dev should be mounted as a tmpfs by the kernel and populated with /dev/null, /dev/console etc. Yet, my buildroot/output/target contains a dev folder with subdirectories created by buildroot.

So, I tried both creating the entries with target/generic_device_table for tty0, tty1, console, null. This works, and udev reports it is scanning for devices and done, yet /dev never picks up e.g. /dev/sda, or /dev/disk/..., or so on. I have, in this configuration, copied /usr/lib/udev/rules.d/* to buildroot/output/target/etc/udev/rules.d to no avail; as far as I can see whatever rules I supply, even from my Fedora or Ubuntu distributions, do not seem to affect udev.

Wondering if this creation method was wrong, I have then removed all of the entries in /dev so that the kernel can mount its own devtmpfs. When booting, /dev/null and /dev/tty1 are reported as missing. I imagine there is nothing in /dev at this stage

Various possibly related points:
* I thought udev required udevd, yet I can't see that either running or
available on the ISO, nor can I find a configuration option to create it.
* I have D-Bus built for the system, as I read udev required it.
* I can see sda1 in /sys/block/sda/sda1; likewise for other attached
storage devices.

Am I doing anything very wrong? I get the feeling I must be missing something for this to not work, yet I'm not sure what.

Can anyone offer any advice? Happy to provide config snippets etc.

Using buildroot 2012.08.

Thanks,

Antony

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Here's what I have minimally in my own buildroot's fs/skeleton/dev folder (which is copied at the end of the buildroot process into output/target/dev )

Quoted 3 lines

Here's what I have minimally in my own buildroot's fs/skeleton/dev folder (which is copied at the end of the buildroot process into output/target/dev )

Err... That can only work if you have sudo in your post-build script
- which
we consider bad practice. We have the device_table to deal with device nodes.
And all of that shouldn't be necessary if you use devtmpfs (or udev or mdev,
which implies devtmpfs). If you use static device nodes, then the default
device_table_dev creates all of those.

If that doesn't work for you, then we should try to fix it in buildroot.

Regards,
Arnout

Hi All,

I'm not using initramfs - I'm using the ISO 9660 target which as far as I can see produces an initrd, a kernel and an ext2 raw image which it mounts as a ramdisk. If I select the initramfs options, the cpio filesystem is generated prior to the iso9660 one, *but the initramfs afterwards!* Which means, as far as I can see, that initramfs would not be placed on the disk - unless buildroot manipulates the iso filesystem post creation? I could of course mkisofs myself, but I was trying to avoid that - although if this fixes udev, I'll do it.

I've nothing /dev related in my fs/skeleton, and only the default values in device_table.txt. Since I'm using udev, I did expect it would populate everything it needed in /dev - although unless I add entries for null, console and a tty into device_table.txt, I end up with a distribution that loops forever saying "could not find /dev/tty1" (if I've configured tty1 as the location for getty for example). I can't mitigate this by re-writing the inittab to launch getty "once" as opposed to respawn, since buildroot rewrites that - and askfirst:/bin/sh works, except that the respawn error messages are written all over /dev/console, making it unusable...!

By the sounds of things this is wrong, but I'm currently attempting to preconfigure some devices in device_table.txt - e.g. /dev/null, /dev/urandom et al pseudo devices, and I'm borrowing Ubuntu's rules.d to see if these are any more effective than Fedora's. Leaving device_table.txt as its default causes the tty1 missing loop. I am not expecting this to work - I cannot see how udev rules differ greatly between distributions - just eliminating it as a possible cause.

Any further ideas as to what I can try? Is mdev a better choice?

Thanks for your help,

Antony

________________

Macrium^(TM) Software is a trading name of Paramount Software UK Ltd, Registered in England and Wales Number 02973414
Registered Office: Kilburn House, Manchester Science Park, Lloyd St. North, Manchester M15 6SE United Kingdom

The information contained in this e-mail is confidential, privileged, or otherwise protected from disclosure. It is intended only for the use of the authorized individual as indicated in the e-mail. Any unauthorized disclosure, copying, distribution or taking of any action based on the contents of this material is strictly prohibited.

If you have received this e-mail in error, please delete it immediately.

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Hi Antony

Just one guestion: What bootloader are you using for your Live CD ? (I use grub)

8.11.2012 11:56, Antony Vennard kirjoitti:

Quoted 11 lines

Hi All,

I'm not using initramfs - I'm using the ISO 9660 target which as far as I can see produces an initrd, a kernel and an ext2 raw image which it mounts as a ramdisk. If I select the initramfs options, the cpio filesystem is generated prior to the iso9660 one, *but the initramfs afterwards!* Which means, as far as I can see, that initramfs would not be placed on the disk - unless buildroot manipulates the iso filesystem post creation? I could of course mkisofs myself, but I was trying to avoid that - although if this fixes udev, I'll do it.

Keep in mind that the buildroot way of making initramfs (that is if you select intramfs from menuconfig) is
to embed your initramfs directly into kernel.

There are three disadvantages in here:

1 ) It will make your kernel fatter
2 ) It will makes things more complicated than necessary You might have two initramfs settings: One that is embedded directly into your kernel and
another that you have made by hand by yourself. And it's very possible that they could have conflicting stuff between them
You can have several initramfs files (at least with grub bootloader), the last ones overlaying the first ones, in order.
3 ) It will makes less flexibe.

All kernels since 2.6 have initramfs inside them, it's just that by default that environment is empty.

Embedding initramfs directly to kernel might be good for those users who don't use any bootloader or are using a bootloader which can't be feeded external, separate initramfs file(s) (like grub) and want to have minimal system always available (as piggybacked inside kernel).

Quoted 19 lines

I've nothing /dev related in my fs/skeleton, and only the default values in device_table.txt. Since I'm using udev, I did expect it would populate everything it needed in /dev - although unless I add entries for null, console and a tty into device_table.txt, I end up with a distribution that loops forever saying "could not find /dev/tty1" (if I've configured tty1 as the location for getty for example). I can't mitigate this by re-writing the inittab to launch getty "once" as opposed to respawn, since buildroot rewrites that - and askfirst:/bin/sh works, except that the respawn error messages are written all over /dev/console, making it unusable...!

By the sounds of things this is wrong, but I'm currently attempting to preconfigure some devices in device_table.txt - e.g. /dev/null, /dev/urandom et al pseudo devices, and I'm borrowing Ubuntu's rules.d to see if these are any more effective than Fedora's. Leaving device_table.txt as its default causes the tty1 missing loop. I am not expecting this to work - I cannot see how udev rules differ greatly between distributions - just eliminating it as a possible cause.

Quoted 2 lines

Any further ideas as to what I can try? Is mdev a better choice?

Well mdev is at least easier to configure than udev.

The only thing you must make sure in your init process is that /proc and /sys are mounted as early as possible (/etc/inittab is good place for that)
and that echo /sbin/mdev > /proc/sys/kernel/hotplug is also somewhere
in /etc/init.d/rcS (maybe at the start of that file)

And check that you have etc/mdev.conf and etc/init.d/S10mdev (witch is called by /etc/init.d/rcS)

This is what I would do (and have done with my live CD) Forget the buildroot way of making initramfs for now and see if you can construct live CD by hand:

1 ) make clean

2 ) make sure you have all the needed init stuff in fs/skeleton/etc directory (inittab, init.d/rcS, init.d/S* files etc.....)
also make sure that sbin/init is a symlink to /bin/busybox
(I have also symlink of init --> /bin/busybox in top of fs/skeleton but I not sure if that is stricly needed ...
I think kernel should be looking from /sbin/init if no other init found)

3 ) do make menuconfig as you would normally but remember to unselect cpio, initramfs and iso9660 from menuconfig
remember to select grub from under Bootloader section if you
don't already have it
don't select too much of stuff even if you have massive amounts
of RAM in your test systems.
reason being that you are making initramfs later here from your
output/target directory and if you have massive
amount's of stuff in there then it will take forever to boot. (I
have managed to do live CD with massive amounts of stuff on it and
booting fast with only 192 MB RAM but that needed some major hacking)

4 ) do make linux-menuconfig and check that under General setup the
setting Initramfs source files is empty
also check the compression support here that you want to use for
your external initramfs (let's suppose its' the default GZ for now)

5 ) do make

6 ) after buildroot has finished make sure that everything is okay in your output/target (check especially boot/ etc/ and /dev directory)
also make sure you have /boot/grub/menu.lst or /boot/grub/grub.conf
(the other is usually just symlink to other) and check it's settings
(If you are not familiar with grub then I can help with it's
settings, especially important is the line where you tell grub the external
initramfs file)
remove the symlink (iso9660 format does not support symlinks)

7 ) Create directory where you want to put your kernel & bootloader (a.ka. the whole contents of /boot dir) and external initramfs file
that is generated next:

mkdir /livecd && cp -r output/target/boot /livecd

8 ) from output/target dir do find . -not \( -path "./boot" -prune
\) -print0 | cpio --null -ov --format=newc | gzip -9 > /livecd/initramfs.gz (we don't need boot directory inside initramfs. it needs to stay outside of it. that why it was copied previously)

9 ) make iso9660 normally from the contents of your /livecd mkdir /livecd_output && cd /livecd && mkisofs --joliet -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -iso-level 4 -hide-rr-moved -c boot.catalog -o /livecd_output/your_livecd.iso .

(remember that . at the end)

10) burn the iso to CD or even better use qemu or VirtualBox to boot your iso without wasting CD disc.

If this manual way worked then next try buildroot way.

Best regards
Stefan

Quoted 25 lines

Thanks for your help,

Antony

________________

Macrium? Software is a trading name of Paramount Software UK Ltd, Registered in England and Wales Number 02973414 Registered Office: Kilburn House, Manchester Science Park, Lloyd St. North, Manchester M15 6SE United Kingdom

The information contained in this e-mail is confidential, privileged, or otherwise protected from disclosure. It is intended only for the use of the authorized individual as indicated in the e-mail. Any unauthorized disclosure, copying, distribution or taking of any action based on the contents of this material is strictly prohibited.

If you have received this e-mail in error, please delete it immediately.

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Hi Stefan,

Thanks for that. I have followed your instructions for making a live cd manually with mkisofs - actually this is helpful since a later job is to add UEFI booting to the disk, which is easier this way (although I am going to look at modifying buildroot, if I can).

I am using grub, and have modified my grub command line to use:

title LiveCD
kernel /vmlinuz vga=0x317
initrd /initramfs.bz2

The kernel has bz2, xz and gzip initramfs support built in - so all good there. However, the kernel complains there's no root parameter. What should I specify for this?

Thanks,

Antony

Quoted 166 lines · Stefan Fr?berg

Hi Antony

Just one guestion: What bootloader are you using for your Live CD ? (I use grub)

8.11.2012 11:56, Antony Vennard kirjoitti:

Quoted 11 lines

Hi All,

I'm not using initramfs - I'm using the ISO 9660 target which as far as I can see produces an initrd, a kernel and an ext2 raw image which it mounts as a ramdisk. If I select the initramfs options, the cpio filesystem is generated prior to the iso9660 one, *but the initramfs afterwards!* Which means, as far as I can see, that initramfs would not be placed on the disk - unless buildroot manipulates the iso filesystem post creation? I could of course mkisofs myself, but I was trying to avoid that - although if this fixes udev, I'll do it.

Keep in mind that the buildroot way of making initramfs (that is if you select intramfs from menuconfig) is
to embed your initramfs directly into kernel.

There are three disadvantages in here:

1 ) It will make your kernel fatter
2 ) It will makes things more complicated than necessary You might have two initramfs settings: One that is embedded directly into your kernel and
another that you have made by hand by yourself. And it's very possible that they could have conflicting stuff between them
You can have several initramfs files (at least with grub bootloader), the last ones overlaying the first ones, in order.
3 ) It will makes less flexibe.

All kernels since 2.6 have initramfs inside them, it's just that by default that environment is empty.

Embedding initramfs directly to kernel might be good for those users who don't use any bootloader or are using a bootloader which can't be feeded external, separate initramfs file(s) (like grub) and want to have minimal system always available (as piggybacked inside kernel).

Quoted 19 lines

I've nothing /dev related in my fs/skeleton, and only the default values in device_table.txt. Since I'm using udev, I did expect it would populate everything it needed in /dev - although unless I add entries for null, console and a tty into device_table.txt, I end up with a distribution that loops forever saying "could not find /dev/tty1" (if I've configured tty1 as the location for getty for example). I can't mitigate this by re-writing the inittab to launch getty "once" as opposed to respawn, since buildroot rewrites that - and askfirst:/bin/sh works, except that the respawn error messages are written all over /dev/console, making it unusable...!

By the sounds of things this is wrong, but I'm currently attempting to preconfigure some devices in device_table.txt - e.g. /dev/null, /dev/urandom et al pseudo devices, and I'm borrowing Ubuntu's rules.d to see if these are any more effective than Fedora's. Leaving device_table.txt as its default causes the tty1 missing loop. I am not expecting this to work - I cannot see how udev rules differ greatly between distributions - just eliminating it as a possible cause.

Quoted 2 lines

Any further ideas as to what I can try? Is mdev a better choice?

Well mdev is at least easier to configure than udev.

The only thing you must make sure in your init process is that /proc and /sys are mounted as early as possible (/etc/inittab is good place for that)
and that echo /sbin/mdev > /proc/sys/kernel/hotplug is also somewhere
in /etc/init.d/rcS (maybe at the start of that file)

And check that you have etc/mdev.conf and etc/init.d/S10mdev (witch is called by /etc/init.d/rcS)

This is what I would do (and have done with my live CD) Forget the buildroot way of making initramfs for now and see if you can construct live CD by hand:

1 ) make clean

2 ) make sure you have all the needed init stuff in fs/skeleton/etc directory (inittab, init.d/rcS, init.d/S* files etc.....)
also make sure that sbin/init is a symlink to /bin/busybox
(I have also symlink of init --> /bin/busybox in top of fs/skeleton but I not sure if that is stricly needed ...
I think kernel should be looking from /sbin/init if no other init found)

3 ) do make menuconfig as you would normally but remember to unselect cpio, initramfs and iso9660 from menuconfig
remember to select grub from under Bootloader section if you
don't already have it
don't select too much of stuff even if you have massive amounts
of RAM in your test systems.
reason being that you are making initramfs later here from your
output/target directory and if you have massive
amount's of stuff in there then it will take forever to boot. (I
have managed to do live CD with massive amounts of stuff on it and
booting fast with only 192 MB RAM but that needed some major hacking)

4 ) do make linux-menuconfig and check that under General setup the
setting Initramfs source files is empty
also check the compression support here that you want to use for
your external initramfs (let's suppose its' the default GZ for now)

5 ) do make

6 ) after buildroot has finished make sure that everything is okay in your output/target (check especially boot/ etc/ and /dev directory)
also make sure you have /boot/grub/menu.lst or /boot/grub/grub.conf
(the other is usually just symlink to other) and check it's settings
(If you are not familiar with grub then I can help with it's
settings, especially important is the line where you tell grub the external
initramfs file)
remove the symlink (iso9660 format does not support symlinks)

7 ) Create directory where you want to put your kernel & bootloader (a.ka. the whole contents of /boot dir) and external initramfs file
that is generated next:

mkdir /livecd && cp -r output/target/boot /livecd

8 ) from output/target dir do find . -not \( -path "./boot" -prune
\) -print0 | cpio --null -ov --format=newc | gzip -9 > /livecd/initramfs.gz (we don't need boot directory inside initramfs. it needs to stay outside of it. that why it was copied previously)

9 ) make iso9660 normally from the contents of your /livecd mkdir /livecd_output && cd /livecd && mkisofs --joliet -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -iso-level 4 -hide-rr-moved -c boot.catalog -o /livecd_output/your_livecd.iso .

(remember that . at the end)

10) burn the iso to CD or even better use qemu or VirtualBox to boot your iso without wasting CD disc.

If this manual way worked then next try buildroot way.

Best regards
Stefan

Quoted 25 lines

Thanks for your help,

Antony

________________

Macrium? Software is a trading name of Paramount Software UK Ltd, Registered in England and Wales Number 02973414 Registered Office: Kilburn House, Manchester Science Park, Lloyd St. North, Manchester M15 6SE United Kingdom

The information contained in this e-mail is confidential, privileged, or otherwise protected from disclosure. It is intended only for the use of the authorized individual as indicated in the e-mail. Any unauthorized disclosure, copying, distribution or taking of any action based on the contents of this material is strictly prohibited.

If you have received this e-mail in error, please delete it immediately.

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Hi Stefan,

Thanks for that. I have followed your instructions for making a live cd manually with mkisofs - actually this is helpful since a later job is to add UEFI booting to the disk, which is easier this way (although I am going to look at modifying buildroot, if I can).

I am using grub, and have modified my grub command line to use:

title LiveCD
kernel /vmlinuz vga=0x317
initrd /initramfs.bz2

The kernel has bz2, xz and gzip initramfs support built in - so all good there. However, the kernel complains there's no root parameter. What should I specify for this?

Thanks,

Antony

Quoted 166 lines · Stefan Fr?berg

Hi Antony

Just one guestion: What bootloader are you using for your Live CD ? (I use grub)

8.11.2012 11:56, Antony Vennard kirjoitti:

Quoted 11 lines

Hi All,

I'm not using initramfs - I'm using the ISO 9660 target which as far as I can see produces an initrd, a kernel and an ext2 raw image which it mounts as a ramdisk. If I select the initramfs options, the cpio filesystem is generated prior to the iso9660 one, *but the initramfs afterwards!* Which means, as far as I can see, that initramfs would not be placed on the disk - unless buildroot manipulates the iso filesystem post creation? I could of course mkisofs myself, but I was trying to avoid that - although if this fixes udev, I'll do it.

Keep in mind that the buildroot way of making initramfs (that is if you select intramfs from menuconfig) is
to embed your initramfs directly into kernel.

There are three disadvantages in here:

1 ) It will make your kernel fatter
2 ) It will makes things more complicated than necessary You might have two initramfs settings: One that is embedded directly into your kernel and
another that you have made by hand by yourself. And it's very possible that they could have conflicting stuff between them
You can have several initramfs files (at least with grub bootloader), the last ones overlaying the first ones, in order.
3 ) It will makes less flexibe.

All kernels since 2.6 have initramfs inside them, it's just that by default that environment is empty.

Embedding initramfs directly to kernel might be good for those users who don't use any bootloader or are using a bootloader which can't be feeded external, separate initramfs file(s) (like grub) and want to have minimal system always available (as piggybacked inside kernel).

Quoted 19 lines

I've nothing /dev related in my fs/skeleton, and only the default values in device_table.txt. Since I'm using udev, I did expect it would populate everything it needed in /dev - although unless I add entries for null, console and a tty into device_table.txt, I end up with a distribution that loops forever saying "could not find /dev/tty1" (if I've configured tty1 as the location for getty for example). I can't mitigate this by re-writing the inittab to launch getty "once" as opposed to respawn, since buildroot rewrites that - and askfirst:/bin/sh works, except that the respawn error messages are written all over /dev/console, making it unusable...!

By the sounds of things this is wrong, but I'm currently attempting to preconfigure some devices in device_table.txt - e.g. /dev/null, /dev/urandom et al pseudo devices, and I'm borrowing Ubuntu's rules.d to see if these are any more effective than Fedora's. Leaving device_table.txt as its default causes the tty1 missing loop. I am not expecting this to work - I cannot see how udev rules differ greatly between distributions - just eliminating it as a possible cause.

Quoted 2 lines

Any further ideas as to what I can try? Is mdev a better choice?

Well mdev is at least easier to configure than udev.

The only thing you must make sure in your init process is that /proc and /sys are mounted as early as possible (/etc/inittab is good place for that)
and that echo /sbin/mdev > /proc/sys/kernel/hotplug is also somewhere
in /etc/init.d/rcS (maybe at the start of that file)

And check that you have etc/mdev.conf and etc/init.d/S10mdev (witch is called by /etc/init.d/rcS)

This is what I would do (and have done with my live CD) Forget the buildroot way of making initramfs for now and see if you can construct live CD by hand:

1 ) make clean

2 ) make sure you have all the needed init stuff in fs/skeleton/etc directory (inittab, init.d/rcS, init.d/S* files etc.....)
also make sure that sbin/init is a symlink to /bin/busybox
(I have also symlink of init --> /bin/busybox in top of fs/skeleton but I not sure if that is stricly needed ...
I think kernel should be looking from /sbin/init if no other init found)

3 ) do make menuconfig as you would normally but remember to unselect cpio, initramfs and iso9660 from menuconfig
remember to select grub from under Bootloader section if you
don't already have it
don't select too much of stuff even if you have massive amounts
of RAM in your test systems.
reason being that you are making initramfs later here from your
output/target directory and if you have massive
amount's of stuff in there then it will take forever to boot. (I
have managed to do live CD with massive amounts of stuff on it and
booting fast with only 192 MB RAM but that needed some major hacking)

4 ) do make linux-menuconfig and check that under General setup the
setting Initramfs source files is empty
also check the compression support here that you want to use for
your external initramfs (let's suppose its' the default GZ for now)

5 ) do make

6 ) after buildroot has finished make sure that everything is okay in your output/target (check especially boot/ etc/ and /dev directory)
also make sure you have /boot/grub/menu.lst or /boot/grub/grub.conf
(the other is usually just symlink to other) and check it's settings
(If you are not familiar with grub then I can help with it's
settings, especially important is the line where you tell grub the external
initramfs file)
remove the symlink (iso9660 format does not support symlinks)

7 ) Create directory where you want to put your kernel & bootloader (a.ka. the whole contents of /boot dir) and external initramfs file
that is generated next:

mkdir /livecd && cp -r output/target/boot /livecd

8 ) from output/target dir do find . -not \( -path "./boot" -prune
\) -print0 | cpio --null -ov --format=newc | gzip -9 > /livecd/initramfs.gz (we don't need boot directory inside initramfs. it needs to stay outside of it. that why it was copied previously)

9 ) make iso9660 normally from the contents of your /livecd mkdir /livecd_output && cd /livecd && mkisofs --joliet -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -iso-level 4 -hide-rr-moved -c boot.catalog -o /livecd_output/your_livecd.iso .

(remember that . at the end)

10) burn the iso to CD or even better use qemu or VirtualBox to boot your iso without wasting CD disc.

If this manual way worked then next try buildroot way.

Best regards
Stefan

Quoted 25 lines

Thanks for your help,

Antony

________________

Macrium? Software is a trading name of Paramount Software UK Ltd, Registered in England and Wales Number 02973414 Registered Office: Kilburn House, Manchester Science Park, Lloyd St. North, Manchester M15 6SE United Kingdom

The information contained in this e-mail is confidential, privileged, or otherwise protected from disclosure. It is intended only for the use of the authorized individual as indicated in the e-mail. Any unauthorized disclosure, copying, distribution or taking of any action based on the contents of this material is strictly prohibited.

If you have received this e-mail in error, please delete it immediately.

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

If you ever want to use the maximum compression method supported by modern kernels (XZ compression)
then change that initramfs generation command to this:

find . -not \( -path "./boot" -prune \) -print0 | cpio --null -ov --format=newc
| xz --check=crc32> /livecd/initramfs.xz

Without that --check=crc32 parameter you won't be able to boot XZ-compressed initramfs.

Quoted 8 lines

If you ever want to use the maximum compression method supported by modern kernels (XZ compression)
then change that initramfs generation command to this:

find . -not \( -path "./boot" -prune \) -print0 | cpio --null -ov --format=newc
| xz --check=crc32> /livecd/initramfs.xz

Quoted 2 lines

Without that --check=crc32 parameter you won't be able to boot XZ-compressed initramfs.

It would be good to have this in buildroot. Care to add a config option
BR2_TARGET_ROOTFS_CPIO_XZ? Using host-xz, of course, since not all systems
have xz installed.

Regards,
Arnout

Quoted 10 lines

If you ever want to use the maximum compression method supported by modern kernels (XZ compression)
then change that initramfs generation command to this:

find . -not \( -path "./boot" -prune \) -print0 | cpio --null -ov --format=newc
| xz --check=crc32> /livecd/initramfs.xz

Without that --check=crc32 parameter you won't be able to boot XZ-compressed initramfs.

It would be good to have this in buildroot. Care to add a config option
BR2_TARGET_ROOTFS_CPIO_XZ? Using host-xz, of course, since not all systems
have xz installed.

Regards,
Arnout

But the real problem now is that grub refuses to load. It just shows Loading stage2 .... and hangs there.

If I copy my old grub stuff (namely, the stage2_eltorito file) from 2012.05 build to inside the boot/grub/ of the new buildroot generated livecd (of course, first mounted throught loopback and copied to some other dir for modifying) and then build the livecd from that manually, it will work and show grub menu normally.

I did a quick *md5sum* and *ls* and there indeed is a difference with the git-version and 2012.05 version of stage2_eltorito file, git-version of stage2_eltorito being very large (258 KB vs. working 103 KB)

[snip]

Quoted 10 lines

But the real problem now is that grub refuses to load. It just shows Loading stage2 .... and hangs there.

If I copy my old grub stuff (namely, the stage2_eltorito file) from 2012.05 build to inside the boot/grub/ of the
new buildroot generated livecd (of course, first mounted throught loopback and copied to some other dir for modifying)
and then build the livecd from that manually, it will work and show grub menu normally.

Quoted 5 lines

I did a quick *md5sum* and *ls* and there indeed is a difference with the git-version and 2012.05 version of
stage2_eltorito file, git-version of stage2_eltorito being very large (258 KB vs. working 103 KB)

Is this on a x86_64 target? Then a difference is that we removed
-fPIC -DPIC from CFLAGS. Can you try if that makes a difference?

Regards,
Arnout

18.11.2012 22:02, Arnout Vandecappelle kirjoitti:

Quoted 12 lines · Stefan Fr?berg

[snip]

Quoted 10 lines

But the real problem now is that grub refuses to load. It just shows Loading stage2 .... and hangs there.

If I copy my old grub stuff (namely, the stage2_eltorito file) from 2012.05 build to inside the boot/grub/ of the
new buildroot generated livecd (of course, first mounted throught loopback and copied to some other dir for modifying)
and then build the livecd from that manually, it will work and show grub menu normally.

Quoted 8 lines

Quoted 5 lines

I did a quick *md5sum* and *ls* and there indeed is a difference with the git-version and 2012.05 version of
stage2_eltorito file, git-version of stage2_eltorito being very large (258 KB vs. working 103 KB)

Is this on a x86_64 target? Then a difference is that we removed
-fPIC -DPIC from CFLAGS. Can you try if that makes a difference?

No, just building i586 target inside 32-bit Fedora 16 host.

Ok, Im now going to rebuild both 2012.05 and latest git again and see what happens.

Regards
Stefan

Quoted 2 lines

Regards,
Arnout

I am using grub, and have modified my grub command line to use:

title LiveCD
kernel /vmlinuz vga=0x317
initrd /initramfs.bz2

The kernel has bz2, xz and gzip initramfs support built in - so all good there. However, the kernel complains there's no root parameter. What should I specify for this?

If you build a cpio rootfs, you shouldn't need any additional command line
parameters because the kernel never gets to mounting the root filesystem. It
just runs the /init in the initramfs.

Using a cpio rootfs should also solve your problems with the device nodes,
because we provide a /init that mounts devtmpfs explicitly.

Regards,
Arnout

I may also potentially be looking to integrate EFI boot into our live CD at some stage - if this is of interest I can have a go at adding this to buildroot also.

Quoted 3 lines · Antony Vennard

I may also potentially be looking to integrate EFI boot into our live CD at some stage - if this is of interest I can have a go at adding this to buildroot also.

I guess that will mean you'll need grub2. A posted grub2 patches a while
ago, if you could get them a spin and give feedback, that would be nice. Or
I can repost them if you like.

Regards,
Arnout

I'm not entirely sure - I believe grub legacy can do efi; Fedora 17 certainly uses uses a variant of grub 0.97 for its EFI bootloader by default, although they're moving to grub2 apparently.

Don't worry, I'll find the patches in git when ready - I can see them in the git log.

Quoted 11 lines

If you build a cpio rootfs, you shouldn't need any additional command line
parameters because the kernel never gets to mounting the root filesystem. It
just runs the /init in the initramfs.

Using a cpio rootfs should also solve your problems with the device nodes,
because we provide a /init that mounts devtmpfs explicitly.

Regards,
Arnout

Yep, I'd come to the conclusion I needed an /init to exist, constructing the root file system. Manually creating the CD as a test, the kernel panics (root file system not found) if init doesn't exist. I used the one from fs/cpio/init as you suggested.

The ram_disk_size parameter does appear to be entirely optional.

I'm now on to the next problem - that script exec's /sbin/init which is really /bin/busybox... which is exiting straight away or crashing, as the kernel is now panicking about an exiting init :(

I'm going to have an experiment with this, see if I can understand what the issue is.

I have also grabbed a copy of buildroot git. Once I've got this working, I'll have a go at modifying buildroot to build iso9660 targets via this mechanism. I'm no expert in this kind of thing, but it'll be a good learning experience.

I may also potentially be looking to integrate EFI boot into our live CD at some stage - if this is of interest I can have a go at adding this to buildroot also.

Thanks for your help,

Antony

I'm not using initramfs - I'm using the ISO 9660 target which as far as I can see produces an initrd, a kernel and an ext2 raw image which it mounts as a ramdisk.

Nope, no sudo in my live Cd.
Just few pre-made device nodes in fs/skeleton/dev

Hi All,

I'm currently looking at using udev for a live cd environment built with buildroot, and I'm having trouble getting udev to pick up the machine's devices.

I have some questions and some details that will (hopefully) help identify my problem

Firstly, my kernel is configured to use devtmpfs:

681:CONFIG_DEVTMPFS=y
682:CONFIG_DEVTMPFS_MOUNT=y

so as I understand it, /dev should be mounted as a tmpfs by the kernel and populated with /dev/null, /dev/console etc.

Yet, my
buildroot/output/target contains a dev folder with subdirectories created by buildroot.

So, I tried both creating the entries with target/generic_device_table for tty0, tty1, console, null. This works,

and udev reports it is scanning for devices and done,
yet /dev never picks up e.g. /dev/sda, or
/dev/disk/..., or so on. I have, in this configuration, copied /usr/lib/udev/rules.d/* to buildroot/output/target/etc/udev/rules.d to no avail; as far as I can see whatever rules I supply, even from my Fedora or Ubuntu distributions, do not seem to affect udev.

Wondering if this creation method was wrong, I have then removed all of the entries in /dev so that the kernel can mount its own devtmpfs. When booting, /dev/null and /dev/tty1 are reported as missing. I imagine there is nothing in /dev at this stage