USB boot success: grml-big-0.5 + grml2hd-0.5.5
Good news: grml2hd 0.5.5 worked on my test user's USB hard drive. The USB drive booted a system from power up to GRML user login prompt with full hardware autodetection.
Here are some observations. In general I'm very happy, I just want to offer some thoughts on room for improvement in grml2hd. GRML is beautiful, don't get me wrong.
* The yaird install dialog box mentions SCSI, but not USB or Firewire. It should mention all three explicitly. I know they are all SCSI to Linux, but please help the user. It's an easy string change.
* The installer undoes its own work. It spends lots of time copying, as it must, but some of what it copies it later deletes - services like apache, mysql. Note that I kept all the default selections.
* I got lots of error and warning messages during this stage - can't stop process, can't delete file, permission denied, things like that; several pages of it; very worrisome and confusing.
* A better way (?) is to copy only what the user wants, rather than asking what to delete after it has all been copied over. Show the menu before the copy, not after. Should save lots of time and errors.
* The chroot jail question is weird and I didn't know how to answer it. There was another question about MySQL that probably shouldn't be there. If the user doesn't want MySQL, just get rid of everything associated.
* The video came out bad. Video for booting from CD-ROM was fine, my font and video scale just what I would expect (without any cheatcodes, just default CD boot). However the USB boot produced an ugly (larger) font size and/or video scale that was also painfully mashed to the left (leftmost character columns not even visible). This was on the same monitor. I don't understand why the difference. CD-ROM video defaults would have been fine for the USB install. We're not talking X here, just text GRML. I did create the X config at the install dialog prompt, but the ugliness lies in the basic GRML screen, not X per se.
* I used ReiserFS 3.x and it worked fine, though there seemed to be some miscellany error messages at boot time about accessing this or that (can't remember what).
* Just before install, I did a full apt-upgrade on the CD-ROM boot system. It seems there are lots of patches since grml-big-0.5. I mention this only so you know what I actually intalled to the hard drive.
* The USB bootup process flashed the screen a few times more than the CD-ROM boot. This flashing must have to do with initrd and all that. It was a little bothersome, that's all. If you can minimize the flashing and jumping, it would be nice. Just keep scrolling the boot text, don't flash around so much.
* Some of our older PCs don't have USB boot support in BIOS. They need "helper boot floppies." It would be nice if the installer could create one as an optional step.
I'm eagerly awaiting grml-big 0.6. I will hold off configuring my user systems until 0.6 is released. How close is it? Last I heard a few more days...
Thanks for this excellent distro and USB support.
Regards, Mark
* Mark or2uvma02@sneakemail.com [20051122 07:15]:
Good news: grml2hd 0.5.5 worked on my test user's USB hard drive. The USB drive booted a system from power up to GRML user login prompt with full hardware autodetection.
Great.
Here are some observations. In general I'm very happy, I just want to offer some thoughts on room for improvement in grml2hd. GRML is beautiful, don't get me wrong.
- The yaird install dialog box mentions SCSI, but not USB or Firewire.
It should mention all three explicitly. I know they are all SCSI to Linux, but please help the user. It's an easy string change.
Thanks, will be fixed.
- The installer undoes its own work. It spends lots of time copying, as
it must, but some of what it copies it later deletes - services like apache, mysql. Note that I kept all the default selections.
You don't have to delete any of the packages. ;-) And it's the nature of a live-cd that package selection and copying isn't that flexible.
- I got lots of error and warning messages during this stage - can't
stop process, can't delete file, permission denied, things like that; several pages of it; very worrisome and confusing.
As long as it does not stop it's nothing to worry about. "Normal debian way of life." ;-)
- A better way (?) is to copy only what the user wants, rather than
asking what to delete after it has all been copied over. Show the menu before the copy, not after. Should save lots of time and errors.
That's not possible, think about the way grml2hd has to run. (Copying all files from the[ un]compressed, loopback mounted squashfs-file.)
- The chroot jail question is weird and I didn't know how to answer it.
There was another question about MySQL that probably shouldn't be there. If the user doesn't want MySQL, just get rid of everything associated.
This derives from the debian package, it's not a grml issue. And such questions are important for some people. Just an example: If you remove postgresql 8.0 who says you would like to remove you postgresql database(s) as well? See the point? If you still think this is a bug/problem please run reportbug against Debian's mysql.
In general: if you don't know how to answer a question just stick to the default. This applies to grml's programs as well as to debian's debconf (that's where such questions derive from).
- The video came out bad. Video for booting from CD-ROM was fine, my
font and video scale just what I would expect (without any cheatcodes, just default CD boot). However the USB boot produced an ugly (larger) font size and/or video scale that was also painfully mashed to the left (leftmost character columns not even visible). This was on the same monitor. I don't understand why the difference. CD-ROM video defaults would have been fine for the USB install. We're not talking X here, just text GRML. I did create the X config at the install dialog prompt, but the ugliness lies in the basic GRML screen, not X per se.
Sorry, I don't have any idea what's going wrong here. Must be initrd related again.
Do you have an LCD or TFT? Do you have an "auto adjust" button on your monitor?
- I used ReiserFS 3.x and it worked fine, though there seemed to be some
miscellany error messages at boot time about accessing this or that (can't remember what).
Sorry, don't know what you mean. :)
- Just before install, I did a full apt-upgrade on the CD-ROM boot
system. It seems there are lots of patches since grml-big-0.5. I mention this only so you know what I actually intalled to the hard drive.
Yes. A new devel release (0.5-2) is available for grml-developers and beta-testers. It includes all the updates of the last few weeks (and including 2.6.14-grml).
- The USB bootup process flashed the screen a few times more than the
CD-ROM boot. This flashing must have to do with initrd and all that. It was a little bothersome, that's all. If you can minimize the flashing and jumping, it would be nice. Just keep scrolling the boot text, don't flash around so much.
Could you provide a screenshot please? grml-autoconfig is the same as on live-cd so it must be an initrd related issue. (IMO too much output is better than the other way around. Helps at debugging. ;-))
- Some of our older PCs don't have USB boot support in BIOS. They need
"helper boot floppies." It would be nice if the installer could create one as an optional step.
Quoting http://wiki.grml.org/doku.php?id=tips ->
| Boot grml via floppy disk | | Your computer can not boot from CD-ROM but provides a floppy disk? | Take a look at btmgr (http://btmgr.webframe.org/) or sbm | (http://linux.simple.be/tools/sbm), they provide support for | booting from CD-ROM via a special floppy disk.
The grml-kernel does not fit with all its features on a floppy disk. So you have to use such a specialized floppy disk.
I'm eagerly awaiting grml-big 0.6. I will hold off configuring my user systems until 0.6 is released. How close is it? Last I heard a few more days...
Oh, I'm not yet sure. If you would like to get something like a stable snapshot join the grml-betatesters (just fill out http://grml.org/beta-tester/) and you will get access to 0.5-2.
Thanks for this excellent distro and USB support.
Great you like it. :) Thanks for your feedback!
regards, -mika-
On Tue, Nov 22, 2005 at 08:25:00AM +0100, Michael Prokop wrote:
- Mark or2uvma02@sneakemail.com [20051122 07:15]:
- Some of our older PCs don't have USB boot support in BIOS. They need
"helper boot floppies." It would be nice if the installer could create one as an optional step.
Quoting http://wiki.grml.org/doku.php?id=tips ->
| Boot grml via floppy disk | | Your computer can not boot from CD-ROM but provides a floppy disk? | Take a look at btmgr (http://btmgr.webframe.org/) or sbm | (http://linux.simple.be/tools/sbm), they provide support for | booting from CD-ROM via a special floppy disk.
Sorry, but this don't work for me... This boot-mgr don't seem to ba able to boot from USB. I have tried on four different PCs. One of them is even capable to boot from USB by its own bios (but extreeemly slooow)
* Josef Wolf <jw@> [20051124 20:12]:
On Tue, Nov 22, 2005 at 08:25:00AM +0100, Michael Prokop wrote:
- Mark or2uvma02@sneakemail.com [20051122 07:15]:
- Some of our older PCs don't have USB boot support in BIOS. They need
"helper boot floppies." It would be nice if the installer could create one as an optional step.
Quoting http://wiki.grml.org/doku.php?id=tips ->
| Boot grml via floppy disk | | Your computer can not boot from CD-ROM but provides a floppy disk? | Take a look at btmgr (http://btmgr.webframe.org/) or sbm | (http://linux.simple.be/tools/sbm), they provide support for | booting from CD-ROM via a special floppy disk.
Sorry, but this don't work for me... This boot-mgr don't seem to ba able to boot from USB. I have tried on four different PCs. One of them is even capable to boot from USB by its own bios (but extreeemly slooow)
*d'oh* Sorry, my fault. I did not take care of booting from USB. :(
I don't know any floppy/booting disks which support booting via USB. If you find one please let me know so I can mention it in the docs.
regards, -mika-
You don't have to delete any of the packages. ;-) ... That's not possible, think about the way grml2hd has to run. (Copying all files from the[ un]compressed, loopback mounted squashfs-file.)
All it would take is a filter to omit specific files. There are various ways to do that. I don't see why it's easier to go back and delete files. It's just as much work to avoid copying specific files as it is to copy-all and then delete them.
This derives from the debian package, it's not a grml issue. And such questions are important for some people.
People booting the CD are probably not running PostgreSQL databases from the CD. I'm not clear why PostgreSQL belongs on a sysadmin CD...but you must have reasons.
Do you have an LCD or TFT? Do you have an "auto adjust" button on your monitor?
It's a CRT monitor; no auto-adjust. I leave the monitor settings exactly as when I use my computer for Windows. I use CD defaults for GRML boot. The grml-CD fonts and video defaults look good. The USB hard drive boot has the ugliness.
Could you provide a screenshot please?
I tried snapping digital photos, but they are bad. The screen has some curvature and the lighting is rotten. I can't freeze the boot process either. Sorrry, I tried! The video card is nVidia GeForce 3.
The grml-kernel does not fit with all its features on a floppy disk. So you have to use such a specialized floppy disk.
I understand the need for specialized floppies, which is why the installer should make them.
Thank you for your detailed responses. I appreciate your hard work very much. Go GRML!
Mark
* Mark or2uvma02@sneakemail.com [20051123 09:01]:
You don't have to delete any of the packages. ;-) ... That's not possible, think about the way grml2hd has to run. (Copying all files from the[ un]compressed, loopback mounted squashfs-file.)
All it would take is a filter to omit specific files. There are various ways to do that. I don't see why it's easier to go back and delete files. It's just as much work to avoid copying specific files as it is to copy-all and then delete them.
Please take a look at the source code of grml2hd to see why we won't integrate such a solution. Saving some few MB when copying >2GB compared with the code complexity such a solution would have, is nothing anyone of us will implement. grml2hd should stay small, maintainable and therefor stable.
This derives from the debian package, it's not a grml issue. And such questions are important for some people.
People booting the CD are probably not running PostgreSQL databases from the CD. I'm not clear why PostgreSQL belongs on a sysadmin CD...but you must have reasons.
Sysadmins have to test stuff with databases. And migrate, backup and restore databases.
Do you have an LCD or TFT? Do you have an "auto adjust" button on your monitor?
It's a CRT monitor; no auto-adjust. I leave the monitor settings exactly as when I use my computer for Windows. I use CD defaults for GRML boot. The grml-CD fonts and video defaults look good. The USB hard drive boot has the ugliness.
Hm interesting, I'll google for it.
Could you provide a screenshot please?
I tried snapping digital photos, but they are bad. The screen has some curvature and the lighting is rotten. I can't freeze the boot process either. Sorrry, I tried! The video card is nVidia GeForce 3.
Ok, no problem. I'll have to ask google anyway.
The grml-kernel does not fit with all its features on a floppy disk. So you have to use such a specialized floppy disk.
I understand the need for specialized floppies, which is why the installer should make them.
Why should the installer create them if they already exist? Anyway, I'll add a hint to http://grml.org/grml2hd/
regards, -mika-
It's just as much work to avoid copying specific files as it is to copy-all and then delete them.
Saving some few MB when copying >2GB compared with the code complexity such a solution would have, is nothing anyone of us will implement. grml2hd should stay small, maintainable and therefor stable.
I agree, grml2hd should stay small, maintainable, and stable. The code complexity is greater now.
It's not a question of saving a few MB; it's a question of creating user systems that are not bogged down with complexities (extra services) they don't need which are also open for hacker attack.
I don't see how copy-some is more complex than delete-some. They are equivalent.
Sure, it's easier to do copy-all; but the script also does delete-some after that. If it just did copy-some, it would not need delete-some. So it saves a step and reduces complexity.
I did not get an impression of stability from the delete-some step. There were tons of errors and warnings, confusing questions, etc. I went over that in a prior message.
Besides, it's only a couple dozen things, not the entire distro.
But I understand you may have special reasons for the arrangement, I just don't see them myself.
Thanks for hearing the idea. Mark
On Wed, Nov 23, 2005 at 02:15:38PM -0700, Mark wrote:
I don't see how copy-some is more complex than delete-some. They are equivalent.
No. Because when copying the files there is no package management available. So everything has to be copied. After that there's a new system on the hd ans thus we have all functions of the package management and can remove stuff easily.
But I understand you may have special reasons for the arrangement, I just don't see them myself.
Maybe my explanation helps. Think about it. There's no other way to install a system with a live-cd. Unless you want to download all packages from the net again.
greets Jimmy
* Mark or2uvma02@sneakemail.com [20051123 22:29]:
It's just as much work to avoid copying specific files as it is to copy-all and then delete them.
Saving some few MB when copying >2GB compared with the code complexity such a solution would have, is nothing anyone of us will implement. grml2hd should stay small, maintainable and therefor stable.
I agree, grml2hd should stay small, maintainable, and stable. The code complexity is greater now.
It's not a question of saving a few MB; it's a question of creating user systems that are not bogged down with complexities (extra services) they don't need which are also open for hacker attack.
Exactly therefor the script 'remove-packages-server' exists and is integrated into grml2hd. The modularity allows to run remove-packages-server even on the harddisk installation, absolutely independent from grml2hd.
I don't see how copy-some is more complex than delete-some. They are equivalent.
No.
Using the existing, working package management is less complex and easier to mantain than rewriting a 'cp -a /from /to' to exclude specific files.
Sure, it's easier to do copy-all; but the script also does delete-some after that. If it just did copy-some, it would not need delete-some. So it saves a step and reduces complexity.
No, the copy-some would add complexity. If you don't believe me just read the source.
I did not get an impression of stability from the delete-some step. There were tons of errors and warnings, confusing questions, etc. I went over that in a prior message.
As long as it does not fail it's not an error but a warning. Warnings are kind of normal behaviour. They just let you know that there *might* be something which *might* lead into problems ("I expected foo but received bar"). As long as it does not fail - therefor interrupts - it's not a problem at all. If you are not used to see warnings, you either aren't used to Debian or your Distro hides such stuff from you.
regards, -mika-
Package management is a valid reason, I agree, but it's possible to use package management on the front end, too.
A package manager can provide a manifest list of files associated with a package. Filtering copy-all through such a list isn't hard.
I have no problem with warnings, but the installer might want to prepare the user in advance to know he isn't getting a broken installation. The fact that the program actually completes execution is not (as a rule) the way to tell whether something was done badly during a run. Yes, lots of scripts I have seen send error messages 2>/dev/null because the author knows the warnings are essentially bogus when he writes the script.
Still all in all I think grml2hd is nice work. I do appreciate the de-select services dialog, thanks.
Mark
On Wed, Nov 23, 2005 at 03:15:55PM -0700, Mark wrote:
Package management is a valid reason, I agree, but it's possible to use package management on the front end, too.
A package manager can provide a manifest list of files associated with a package. Filtering copy-all through such a list isn't hard.
Since cp has no exclude function it has to be done with scripting magic. This would add a lot of code to make it work stable. I tried several ways of copying the system to hd with modifications of the original system. This always ended up in code that was terrible. One important point is the time the installer takes. Copy all and remove some packages is the fastest way.
greets Jimmy
First the argument was: technical reasons make your grml2hd proposal more complex than current behavior.
Then I spelled out how easy it is.
Next the argument became: your user scenario fails to consider a hypothetical alternative user scenario. But...
Multiple (bulk) install schemes argue more strongly for the idea. So let me close by addressing install scenarios.
only chance to restore the original state is to reboot. :-/
Of course, but so what:
After running grml2hd, what do I likely want? Probably to boot the hard drive and check it out. That means, reboot the PC. This is probably 80% of cases. One drive, one install.
Just to be fair, let's say no, I really want to stay in GRML-CD after setting up the hard drive.
All right, I have just spent 30 minutes doing an install. Assuming there is a magical package missing from CD at the moment, is a 1-minute reboot such inconvenience after 30 minutes? For one package, can't I just apt-install from the net with no reboot? Of course.
The other cases are mass-installs, as Michael said, "you want to install grml again."
What type of grml do I want to mass-install? Probably identical configs to all users. (This is actually my case.) So it does not hurt to remove the ISO packages first. In fact, it helps (read on).
Now let's be perverse. What if I need different package configs for each user? The only way to get them is by hand. Will I prefer to work by hand under chroot from GRML-CD, or by booting each separate hard drive individually? A good sysadmin does the latter. Not only because it's cleaner, but to validate the user systems. Otherwise the users complain to the boss. If I were doing chroot to many drives, things would get confusing very fast (which drive is current chroot?) and I would make mistakes.
Bottom line: Most people will do a single-disk install. The few bulk installers will largely do same-system installs and boot HDs separately for tweaks (if any).
Finally,
Modifying the live-iso needs more "power" than accessing files in the chroot installed on harddisk.
Not in the mass install scenario, which multiplies the pacakage removal task by the number of hard drives (whether chroot or straight). It's simpler to do once from CD and then mass install to drives.
In the single drive case I doubt it's a difference worth argument. CD removal takes slightly longer, but also saves file copy time during copy-all to disk. People can quibble about details.
If you think you don't need the packages "foo, bar, blubs, blah" then just run 'apt-get remove foo bar blubs blah' - but it's on your own risk. Running it in the harddisk system is more safe.
Yes I thought of that. Safety issues by themselves argue for changing grml2hd scripts. But it can be done.
The "bad error/warning messages" derives from debian package management
Some seem like chroot problems to me but - fine, okay, I won't dispute that.
I will leave things here. Argue more if you like, but GRML asked for user feedback and that's mine. I'm a real user, not a hypothetical.
Until the next idea ;-) Mark
* Mark or2uvma02@sneakemail.com [20051127 01:15]:
only chance to restore the original state is to reboot. :-/
Of course, but so what:
After running grml2hd, what do I likely want? Probably to boot the hard drive and check it out. That means, reboot the PC. This is probably 80% of cases. One drive, one install.
Just to be fair, let's say no, I really want to stay in GRML-CD after setting up the hard drive.
All right, I have just spent 30 minutes doing an install. Assuming there is a magical package missing from CD at the moment, is a 1-minute reboot such inconvenience after 30 minutes?
Yes, rebooting might be inconvenient if you run grml2hd in automatic installation mode. Or if you don't have physical access to the computer.
For one package, can't I just apt-install from the net with no reboot? Of course.
Not everyone has network access when running grml2hd.
[...]
Modifying the live-iso needs more "power" than accessing files in the chroot installed on harddisk.
Not in the mass install scenario, which multiplies the pacakage removal task by the number of hard drives (whether chroot or straight). It's simpler to do once from CD and then mass install to drives.
In the single drive case I doubt it's a difference worth argument. CD removal takes slightly longer, but also saves file copy time during copy-all to disk. People can quibble about details.
If you don't want to remove the packages *inside* the chroot but on the running CD just run 'remove-packages-server' before calling grml2hd.
If you think you don't need the packages "foo, bar, blubs, blah" then just run 'apt-get remove foo bar blubs blah' - but it's on your own risk. Running it in the harddisk system is more safe.
Yes I thought of that. Safety issues by themselves argue for changing grml2hd scripts. But it can be done.
The "safety issue" is not a problem of grml2hd or grml. It depends on the reliability of unionfs and present RAM.
regards, -mika-
Maybe my explanation helps. Think about it. There's no other way to install a system with a live-cd. Unless you want to download all packages from the net again.
greets Jimmy
It's fairly simple. You boot the live CD. It has services you don't want on installed to the USB drive. So, the installer script, prior to copy-all, just invokes the CD's own package manager and un-installs the unwanted packages from the running CD system. Then it performs the copy-all to hard disk.
Nothing extra to download, nothing extra to delete from the hard drive. All done with package management. Faster execution time and no bad error/warning messages.
Thank you Jimmy, Mark
* Mark or2uvma02@sneakemail.com [20051124 00:09]:
Maybe my explanation helps. Think about it. There's no other way to install a system with a live-cd. Unless you want to download all packages from the net again.
greets Jimmy
It's fairly simple. You boot the live CD. It has services you don't want on installed to the USB drive. So, the installer script, prior to copy-all, just invokes the CD's own package manager and un-installs the unwanted packages from the running CD system. Then it performs the copy-all to hard disk.
No, bad idea. Let's say you want to install grml again (on another disk/device) but don't want to remove for example apache this time. Won't work if it's already deleted in the running system itself. The only chance to restore the original state is to reboot. :-/
If you think you don't need the packages "foo, bar, blubs, blah" then just run 'apt-get remove foo bar blubs blah' - but it's on your own risk. Running it in the harddisk system is more safe.
Modifying the live-iso needs more "power" than accessing files in the chroot installed on harddisk. Removing files on a (basically) read-only medium where a overlay system manages read-write-tasks requires ressources.
Nothing extra to download, nothing extra to delete from the hard drive. All done with package management. Faster execution time and no bad error/warning messages.
The "bad error/warning messages" derives from debian package management and not from grml2hd! It does not matter whether you run this *before* starting grml2hd, *within* grml2hd or afterwards.
regards, -mika-
On Wed, Nov 23, 2005 at 03:37:12PM -0700, Mark wrote:
Maybe my explanation helps. Think about it. There's no other way to install a system with a live-cd. Unless you want to download all packages from the net again.
It's fairly simple. You boot the live CD. It has services you don't want on installed to the USB drive. So, the installer script, prior to copy-all, just invokes the CD's own package manager and un-installs the unwanted packages from the running CD system. Then it performs the copy-all to hard disk.
Mika already mentioned why this approach is not used. But you can use this method yourself manually. Deinstall the packages and then run grml2hd. Or write yourself a simple script to handle it for you.
greets Jimmy
participants (4)
-
Andreas Gredler -
Josef Wolf -
Mark -
Michael Prokop