Re: Reinventing the Hurd server bootstrap
Hi, Well, the overall question is: Is it worth an effort ? I guess it could. Then we wouldn't need to make /dev a tmpfs and create it's content on demand. Then again, doing so is easy enough (with the bootshell). So this discussion was mainly for my curiosity. If the need arises to implement extra features in ISO 9660 production, then don't hesitate to ask e.g. on bug-xorr...@gnu.org. Have a nice day :) Thomas
Re: [PATCH 8/8] startup: bind the startup server to /servers/startup
On Tue, Jan 27, 2015 at 6:35 PM, Samuel Thibault samuel.thiba...@gnu.org wrote: Justus Winter, le Fri 16 Jan 2015 11:15:37 +0100, a écrit : Quoting David Michael (2014-09-18 23:14:17) On Wed, Sep 3, 2014 at 8:33 AM, Justus Winter 4win...@informatik.uni-hamburg.de wrote: Bind the startup server to /servers/startup instead. Use this to contact the startup server. I'm trying to test this patch, and glibc appears to need an update as well. Does this look okay? Please apply this patch to the Debian libc. I uploaded it to debian-ports the other day. But as Ludo mentioned, we need to push patches upstream too. I can try creating a proper patch and submitting it upstream over the weekend, unless someone else is already planning to do so. Thanks. David
Re: Reinventing the Hurd server bootstrap
Quoting Thomas Schmitt (2015-01-30 14:25:50) Hi, Justus Winter wrote: 3. Remaster using `grub-mkrescue --output=my-bootshell.iso /=master'. The beauty of grub-mkrescue. Yes, it's super nice :) To start an translator on demand, the file system needs to support storing a passive translator record somewhere. [...] I don't know if it would be possible to store it on a cd. At what time would it have to be written ? If it's when the ISO is produced, then one just would have to negociate a suitable representation between xorriso and Hurd. Production time. If it needs write capability at mount time, then it depends on the medium type. It would also break the model of a read-only filesystem. It does not. I read https://www.debian.org/ports/hurd/hurd-doc-translator Can you be more precise, e.g. cite the paragraph in question? I mean the underlying inode the translator is attached to, which gets introduced in #concept, demonstrated as mount point in #examples, and referred to in #actpas: [...] the first time the passive translator is accessed, it is automatically read out of the inode and an active translator is started on top of it using the command line that was stored in the inode. Is this inode the mount point directory inode in the parent filesystem (e.g. in ext2) or is it the root directory of the ISO filesystem ? The former. Though it doesn't need to be a directory node. On the CD, /run is a simple empty file. (Or does each inode of the ISO get attached a translator ?) No. ext2fs stores the record in the operating system specific part of the ext2 ondisk format. That is undesireable for ext2. Well, the System Area of ISO 9660 is playground of GRUB2 in this case. So it would be unwise to use it for translator info without coordination with GRUB2. The System Use Area of the . Directory Record in the extent of the ISO 9660 root directory would be a fine place for extra info. That's were SUSP and Rock Ridge info gets stored. One could define a new SUSP field for Hurd translators or use my AAIP extension, which i use to store Linux-ish xattr and ACL. http://libburnia-project.org/wiki/AAIP In the latter case one would define one or more variable names in name space isofs or system. (Depends on how close one wants to stay with Linux xattr habits.) Well, the overall question is: Is it worth an effort ? I.e. can the ISO stay read-only and does a passive translator provide advantages ? I guess it could. Then we wouldn't need to make /dev a tmpfs and create it's content on demand. Then again, doing so is easy enough (with the bootshell). :) Justus
Re: FOSDEM talk?
Quoting Samuel Thibault (2015-01-30 02:02:33) Hello, About the Hurd news in my slides, in recent work, I have listed: - Init system decoupled - Allows to use standard Debian sysvinit scripts! - Using dmd for Guix such - Distributed mtab translator - Various optimizations - Protected payloads - Lockless implementations - Paging management - Improved message dispatch - Valgrind start-of-port - Merge of procfs/random to make life easier for downstream distros and in future work, I have listed the usual TODO list, plus: - Debian GNU/Hurd unofficial Jessie - Server startup in scheme? Yes please :) Justus
Re: Reinventing the Hurd server bootstrap
Hello :) I produced a demo live cd using my new bootshell: http://darnassus.sceen.net/~teythoon/booting-debian-preboot.png http://darnassus.sceen.net/~teythoon/booting-debian-boot.png http://darnassus.sceen.net/~teythoon/bootshell0129.iso.xz Notable features: * Boots an unmodified Debian (debootstrap --variant=minbase) from a readonly filesystem that does not support passive translators (iso9660fs). * Starts the Hurd console early on, and executes sysvinit in a way that the log messages get sent to tty1. This looks much cleaner, and we do not lose any messages when the console starts up later. * libreadline. Cheers, Justus
Re: Reinventing the Hurd server bootstrap
Hi, http://darnassus.sceen.net/~teythoon/bootshell0129.iso.xz Was it produced by grub-mkrescue ? * Boots an unmodified Debian (debootstrap --variant=minbase) from a readonly filesystem that does not support passive translators (iso9660fs). Would that support be desirable and what properties would an ISO 9660 filesystem have to provide ? I read https://www.debian.org/ports/hurd/hurd-doc-translator Do i get it right that the mentioned inode is the one of the mount point and not an inode-equivalent inside the ISO ? Have a nice day :) Thomas
Re: Reinventing the Hurd server bootstrap
Hi, Justus Winter wrote: 3. Remaster using `grub-mkrescue --output=my-bootshell.iso /=master'. The beauty of grub-mkrescue. More people should use it and increase its weight in GRUB2. Even in the simple BIOS case, it already hides these expert options of xorriso: --grub2-mbr ...disk.path... --protective-msdos-label -c '/boot.catalog' -b '/boot/grub/i386-pc/eltorito.img' -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info To start an translator on demand, the file system needs to support storing a passive translator record somewhere. [...] I don't know if it would be possible to store it on a cd. At what time would it have to be written ? If it's when the ISO is produced, then one just would have to negociate a suitable representation between xorriso and Hurd. If it needs write capability at mount time, then it depends on the medium type. It would also break the model of a read-only filesystem. I read https://www.debian.org/ports/hurd/hurd-doc-translator Can you be more precise, e.g. cite the paragraph in question? I mean the underlying inode the translator is attached to, which gets introduced in #concept, demonstrated as mount point in #examples, and referred to in #actpas: [...] the first time the passive translator is accessed, it is automatically read out of the inode and an active translator is started on top of it using the command line that was stored in the inode. Is this inode the mount point directory inode in the parent filesystem (e.g. in ext2) or is it the root directory of the ISO filesystem ? (Or does each inode of the ISO get attached a translator ?) ext2fs stores the record in the operating system specific part of the ext2 ondisk format. That is undesireable for ext2. Well, the System Area of ISO 9660 is playground of GRUB2 in this case. So it would be unwise to use it for translator info without coordination with GRUB2. The System Use Area of the . Directory Record in the extent of the ISO 9660 root directory would be a fine place for extra info. That's were SUSP and Rock Ridge info gets stored. One could define a new SUSP field for Hurd translators or use my AAIP extension, which i use to store Linux-ish xattr and ACL. http://libburnia-project.org/wiki/AAIP In the latter case one would define one or more variable names in name space isofs or system. (Depends on how close one wants to stay with Linux xattr habits.) Well, the overall question is: Is it worth an effort ? I.e. can the ISO stay read-only and does a passive translator provide advantages ? Have a nice day :) Thomas
Re: Reinventing the Hurd server bootstrap
Quoting Thomas Schmitt (2015-01-30 12:04:57) http://darnassus.sceen.net/~teythoon/bootshell0129.iso.xz Was it produced by grub-mkrescue ? Yes. It is very easy to remaster: 1. Unpack bootshellXX.iso into a dir, e.g. `master'. Use /hurd/iso9660fs on Hurd, or fuseiso, or file-roller on Linux. 2. Hack on `master/hurd/runsystem.scm'. 3. Remaster using `grub-mkrescue --output=my-bootshell.iso /=master'. * Boots an unmodified Debian (debootstrap --variant=minbase) from a readonly filesystem that does not support passive translators (iso9660fs). Would that support be desirable and what properties would an ISO 9660 filesystem have to provide ? To start an translator on demand, the file system needs to support storing a passive translator record somewhere. Currently, ext2fs and tmpfs are the only filesystems that supports that. ext2fs stores the record in the operating system specific part of the ext2 ondisk format. That is undesireable for ext2. A better way would be to store the record in extended attributes. I don't know if it would be possible to store it on a cd. The live cd mounts a tmpfs on /dev and creates all device files. I read https://www.debian.org/ports/hurd/hurd-doc-translator Do i get it right that the mentioned inode is the one of the mount point and not an inode-equivalent inside the ISO ? Can you be more precise, e.g. cite the paragraph in question? Justus
Re: Reinventing the Hurd server bootstrap
On Fri, 2015-01-30 at 13:02 +0100, Justus Winter wrote: Quoting Thomas Schmitt (2015-01-30 12:04:57) Would that support be desirable and what properties would an ISO 9660 filesystem have to provide ? To start an translator on demand, the file system needs to support storing a passive translator record somewhere. Currently, ext2fs and tmpfs are the only filesystems that supports that. ext2fs stores the record in the operating system specific part of the ext2 ondisk format. That is undesireable for ext2. A better way would be to store the record in extended attributes. Isn't there a patch available already for this? http://savannah.gnu.org/patch/?5126 See also http://savannah.gnu.org/task/?5503 https://lists.debian.org/debian-kernel/2014/03/msg00199.html I don't know if it would be possible to store it on a cd.
