Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy

For talk and support relating specifically to Puppy derivatives
Message
Author
User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2241 Post by saintless »

fredx181 wrote:If this is really an obstacle, I've thought about a different setup:

- I can change extension to .squashfs instead of .xzm in initrd1.xz
- put 021-apps-porteus.squashfs in live/debian/modules folder.
- put 01-filesystem.squashfs in live/debian/base

Didn't test this yet but it should work I think if there is included in boot options for DebianDog-live-boot: "live-media-path=/live/debian/base"
It's easy to do but do we want a change like this.
Hi, Fred.
Not an obstacle since I'm sure the user will chose one of the boot ways and delete the second initrd file.
But from what I tested in the past I think it will not work. The last subfolder for live boot has be named /live so it should be live-media-path=/live/debian/base/live. At least with Grub Legacy the last subfolder has to be named /live.

If it works and you see this easier than editing debdog-install I do not mind. I will rebuild the kernel separate modules for the new live-media-path but I might need some help to edit the existing 3 porteus initrd.xz files for DebianDog.

Edit: I found my post about testing live-media-path. I'm sure it does not work if last subfolder is not named /live with Grub legacy. I guess boot=live kernel paramether is the problem to change last subfolder to different name? I'm not sure boot=live can be changed:
...this is the way to use debian live in different folder (/debian-wheezy for example). Move live folder in /debian-wheezy and use this boot code:

Code: Select all

title Wheezy 1
rootnoverify (hd0,0)
kernel /debian-wheezy/live/vmlinuz1 boot=live config persistence live-media-path=/debian-wheezy/live/ quickreboot noautologin noeject
initrd /debian-wheezy/live/initrd1.img
boot
Toni

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#2242 Post by mcewanw »

Fred, Toni: If addressing fat partitions is really going to result in an almost doubling in size of the iso, then why not just make two iso's - one for each method and let the user decide what to download? I don't see the point in doubling the iso when two small iso's would cater for all needs. A small iso is one of the major attractions of Puppy Linux and of DebianDog so far.
github mcewanw

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2243 Post by saintless »

mcewanw wrote:Fred, Toni: If addressing fat partitions is really going to result in an almost doubling in size of the iso, then why not just make two iso's - one for each method and let the user decide what to download? I don't see the point in doubling the iso when two small iso's would cater for all needs. A small iso is one of the major attractions of Puppy Linux and of DebianDog so far.
Hi, William.
The iso size will stay the same. Only if using Fat flash drive it will copy the main module two times on the flash drive.

The point to make DebianDog booting both ways was to have separate module with porteus changes and to keep the debian main module untouched while booting both initrd methods.

Making separate iso versions will make PorteusDog 10 Mb smaller and DebianDog 6Mb smaller but keeping separate porteus changes folder is not needed then. They can be added in the main module. It also means PorteusDog is not 100% debian anymore but different version of Porteus-Wheezy. If Fred agree it should go in Porteus-Wheezy folder.

I'm more interested from debian boot method and I seldom use porteus boot. Separating the iso versions will make more difficult to update both versions with the changes and to test if something added breaks porteus or debian boot.

I do not mind separate versions but I think one of the advantages of DebianDog will be the simple switch from debian to porteus included in only one small iso which worth adding the size of one more initd file.
Is it worth to change this just because it is not convenient for Fat flash drive?

Toni

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#2244 Post by fredx181 »

Hi Toni
Not an obstacle since I'm sure the user will chose one of the boot ways and delete the second initrd file.
But from what I tested in the past I think it will not work. The last subfolder for live boot has be named /live so it should be live-media-path=/live/debian/base/live. At least with Grub Legacy the last subfolder has to be named /live.
If it works and you see this easier than editing debdog-install I do not mind.
It's not about editing debdog-install for me.
It's about trying to get rid of the symlink in case using FAT, so if the user wants to make it work it results in almost double size.

As William suggested two iso's will solve it but here's a different setup I made with a changed initrd1.xz.
The directory setup is also different; in a nutshell:
- The 'debian' folder is changed to 'live' so the subfolders e.g. base, modules are in live folder.
- When using porteus-boot, searching for modules will be in 'live' 'live/base' and 'live/modules'
- extension for porteus-boot modules is .squashfs instead of .xzm

No difference for the live-boot boot options.

For porteus boot there are:
When folder 'live' is on the root of a drive you'd maybe expect the "from=/live/" should work.
It doesn't, it should be "from=/" or completey leave out the 'from' parameter is the same.
Two examples for grub(4dos):
Folder live is at root of drive (no 'from' parameter):

Code: Select all

 title Live-port-dog (sda1/live)
  root (hd0,0)
  kernel /live/vmlinuz1 noauto copy2ram  changes=/live/
  initrd /live/initrd1.xz
Folder 'live' is inside folder 'debdog' (needs 'from' parameter):

Code: Select all

 title Live-port-dog from debdog (sda1/debdog)
  root (hd0,0)
  kernel /debdog/live/vmlinuz1 noauto copy2ram from=/debdog/  changes=/debdog/live/
  initrd /debdog/live/initrd1.xz
It keeps the idea of having two-in-one intact but as I said two separate iso's is also fine by me.

EDIT: Forgot to mention:
Do NOT change the name of the 'live' folder or there's no way to make porteus-boot work

EDIT2: New revision of DebianDog-PorteusDog-new-setup.tar.gz uploaded:
The base_only boot option didn't work previously, now it does.

DebianDog-PorteusDog-new-setup.tar.gz:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing

To edit the other initrd's for other kernels it's just a matter of replacing linuxrc, it's the only file I changed and should work with the others AFAIK.

Fred
Last edited by fredx181 on Wed 09 Apr 2014, 09:41, edited 2 times in total.

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#2245 Post by fredx181 »

Hi Toni
It also means PorteusDog is not 100% debian anymore but different version of Porteus-Wheezy.
I can't see why it's not 100% debian anymore, what would be the difference then, because of boot-method?
Can you explain?

Fred

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2246 Post by saintless »

Thank you, Fred!
I will test the new setup mode and write back.
I can't see why it's not 100% debian anymore, what would be the difference then, because of boot-method?
Can you explain?
Because it does not use debian initrd file anymore, Fred.
You can't ask in debian forum for help how to make changes=EXIT to work for example. You can't use the documentation about live-boot v2 or v3 codes while using porteus boot method. This is what I mean by not 100% debian anymore.
The mount point with porteus initrd file is different. It is /media in debian and /mnt in porteus. Such small changes might seems not important but they make difference when you ask for help in debian forum.

The same way we can use 01-filesystem.squashfs to boot with some puppy initrd and kernel and it will. Is it still 100% debian?
Or as already tested we can boot any puppy with our separate kernel modules and having /live/cow and /live/image while using puppy. Is it still 100% puppy?

For example the questions Terry asks in debian users forum get the proper answers about the boot process. Nobody asks him why you use live-boot v.2 with Wheezy? He gets answer about DebianDog boot process in debian users forum. It will not happen if he asks for Porteus boot method.

I want DebianDog users to be able to ask questions and get help in debian forums and debian documentation to be valid all the way for DebianDog. We will not be able to answer all the questions all the time in the future in this thread.

Toni

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#2247 Post by fredx181 »

Toni wrote:I want DebianDog users to be able to ask questions and get help in debian forums and debian documentation to be valid all the way for DebianDog. We will not be able to answer all the questions all the time in the future in this thread.
Yes I see what you mean now, Thanks!

Fred

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2248 Post by saintless »

fredx181 wrote:DebianDog-PorteusDog-new-setup.tar.gz:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing

To edit the other initrd's for other kernels it's just a matter of replacing linuxrc, it's the only file I changed and should work with the others AFAIK.
Thank you, Fred! looks great to me this way :)
I will change the iso structure to this one and rebuild the other porteus initrd files with changed linuxrc file.
We keep one iso with both boot methods.

Toni

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#2249 Post by fredx181 »

Hi Toni :)
That's nice, FAT issue solved!

But the PorteusDog users cannot ask anything in the Porteus forum anymore now :wink:
Well, no, before they also couldn't anyway.

There's one small downside, I've done an Edit in my post about it also:
Do NOT change the name of the 'live' folder or there's no way to make porteus-boot work, it depends on the name 'live' now.
It's the same as previously the name 'debian' could not be changed.

Btw, what you said about 'live-media-path=' option that it needs to be 'live' is not true.
I've many times used it without 'live' folder, no problems.
To take your example:

Code: Select all

title Wheezy 1
rootnoverify (hd0,0)
kernel /debian-wheezy/live/vmlinuz1 boot=live config persistence live-media-path=/debian-wheezy/live/ quickreboot noautologin noeject
initrd /debian-wheezy/live/initrd1.img
boot
If you would move everything that's inside /debian-wheezy/live/ to /debian-wheezy and then:

Code: Select all

title Wheezy 1
rootnoverify (hd0,0)
kernel /debian-wheezy/vmlinuz1 boot=live config persistence live-media-path=/debian-wheezy/ quickreboot noautologin noeject
initrd /debian-wheezy/initrd1.img
It should work.

Fred

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2250 Post by saintless »

Hi, Fred.
fredx181 wrote:

Code: Select all

title Wheezy 1
rootnoverify (hd0,0)
kernel /debian-wheezy/vmlinuz1 boot=live config persistence live-media-path=/debian-wheezy/ quickreboot noautologin noeject
initrd /debian-wheezy/initrd1.img
It should work.
Just tested the same code and I can't make it boot. I get file not found boot message. The strange thing is I can't make it boot now even with live-media-path=/debian-wheezy/live/ and I'm sure I have it working this way before.

I will try in the next days with different Grub installed from puppy and grub4dos from debdog-install on the usb.
I use Grub legacy from old version of GeexBox live cd for HDD install at the moment.

Do NOT change the name of the 'live' folder or there's no way to make porteus-boot work, it depends on the name 'live' now.
It's the same as previously the name 'debian' could not be changed.
Thanks, I will add this information on the site. The boot structure will by easy to change back by downloading the previous initrd.xz files from the site. I will keep them for separate download.

Toni

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#2251 Post by fredx181 »

Hi Toni
Just tested the same code and I can't make it boot
Just in case you didn't see: that code has 'persistence' as boot parameter which is, as you know, for live-boot v3.

Fred

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2252 Post by saintless »

No, persistence or persistent does not make boot problems for any version of live-boot. I mixed them more than once while testing the first base for Light-Wheezy. Just the save file will not be loaded if the wrong one is used.
The problem is somewhere else.

Toni

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#2253 Post by mcewanw »

saintless wrote: Hi, William.
The iso size will stay the same. Only if using Fat flash drive it will copy the main module two times on the flash drive.
Ah, okay, I misunderstood. I'm relieved it is that way. It is good to have both options in the one iso, when there is no huge size penalty, of course.
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#2254 Post by mcewanw »

saintless wrote: Just tested the same code and I can't make it boot. I get file not found boot message. The strange thing is I can't make it boot now even with live-media-path=/debian-wheezy/live/ and I'm sure I have it working this way before.
Hi Toni, maybe nothing to do with it, but good if you could test on newer machine than your old 128MB grunter. I do most of my testing on my own old machine here, which doesn't boot from usb. However, my installations are all on usb flash because the hard disk is failing on this machine. I manage that because I have grub4dos/menu.list/grldr on hard drive and the menu.lst instructed to find kernel etc on the usb flash (doesn't need a bootable flash of course). However, I do have weird issues 'sometimes' and very unpredicatable where I sometimes on the same usb flash get 'file not found boot message'. Usually after deleting and installing some new stuff. The other thing is I currently can boot debiandog from current usb but no longer Puppy guydog (file not found boot message for that one). I have come to the conclusion that my old machine has these BIOS/ATA limitations (no of heads, cylinders, usb size etc) such that BIOS can sometimes luckily find vmlinuz etc if it happens to be on earlier enough cylinder and low down in the GB. Once vmlinuz etc is booting it takes over from the BIOS so the rest of the system works fine thereafter - that's my intuitive suspicion anyway (I've been messing around with fdisk expert mode to try and prove it one way or the other, but nothing conclusive so far...). There are certainly many limits that could come into play - these old machines are not expecting large hard drives and usb flash view of the chs situation probably even worse for them:

http://www.tldp.org/HOWTO/Large-Disk-HOWTO-4.html

Certainly, in the past, when larger hard discs started coming out, it was important to create a small partition for the bootup files alone (vmlinux etc, which was in /boot usually, so /boot mounted to own small partition back then), in low down cylinders etc - otherwise bios couldn't find vmlinuz.

If I'm right, that would explain much mysterious behaviour when sometimes the same thing seems to work and other times it doesn't. Nothing to do with filesystem formats, in such cases, though might depend sometimes on the boot loader programs (grub/syslinux/wee etc) capabilities also.

I have one 4GB usb flash stick that always refused to boot from my grub4dos setup, but last night after mucking around with fdisk expert mode changing amount of cylinders seen etc, I somehow had debiandog booting from it in a 1 GB ext4 partition. Unfortunately, I wiped it without noting down what I did and I'm been starting from scratch trying to repeat that success ever since! In attempts since I just get the file not found boot message, and in some attempts the machine actually freezes on boot attempt needing a power off before trying again. However I do have debiandog booting from a different flash stick of even greater size (8GB) on this machine (via hard disk grub4dos arrangement). On that one I have an empty first 1GB fat32 partition, followed by a 6GB ext4 partition with debiandog on it and also Puppy guydog (which as I say won't boot, yet debiandog does... all very weird - the same usb flash drives all boot fine on my other newer machine)

Having said all of the above, to be honest, I have no idea what the issue is - maybe nothing to do with BIOS at all, though why I got that 4GB card working only once and why debiandog visible and guydog not on same partition is a real mystery...
github mcewanw

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2255 Post by saintless »

Hi, William.
mcewanw wrote:Hi Toni, maybe nothing to do with it, but good if you could test on newer machine than your old 128MB grunter.
Thanks, I also suspect this could be the cause of my troubles or the version of Grub I have. I will use grub4dos test on another computer today. I need to be sure it is not a problem caused from the remount /live/image line and one squeeze path_id file added in initrd.img

Thanks to Fred we will not use symlink in the iso and vfat partition issue is solved.

Toni

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

BIOS/ATA limitations workaround found

#2256 Post by mcewanw »

mcewanw wrote:I have come to the conclusion that my old machine has these BIOS/ATA limitations (no of heads, cylinders, usb size etc) such that BIOS can sometimes luckily find vmlinuz etc if it happens to be on earlier enough cylinder and low down in the GB. Once vmlinuz etc is booting it takes over from the BIOS so the rest of the system works fine thereafter - that's my intuitive suspicion anyway
My intuition seems to have proved correct Toni. I now have Debiandog booting from my tricky 4GB usb.
EDIT:

However, I have edited this post and removed the previous txt, which I wrongly thought was the 'solution'.

In case someone else has similar problems with debiandog not booting from usb stick on older machine they might like to try my suggestion in post below (though may or may not work - I only know it works on my old machine):

http://www.murga-linux.com/puppy/viewto ... 156#770156
Last edited by mcewanw on Wed 09 Apr 2014, 04:28, edited 3 times in total.

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

Re: BIOS/ATA limitations workaround found

#2257 Post by saintless »

Hi, William.
mcewanw wrote:This could have important implications for debdog-install, if what I have found proves correct, if we want it to work on old machines - should arrange for vmlinuz to be copied first and then a sync before the rest.
... simply renaming it to say 'avmlinuz' would copy it early during installation...
Renaming vmlinuz is not possible in iso install option I think.
There is no need to make debdog-install so complicated since the problems you have on your old hardware are not the same on mine much older hardware. I even doubt someone else will use DebianDog on old hardware like mine.
I have no problem to boot 512Mb and 8Gb flash drive using debdog-install latest version. The copy order of vmlinuz is the same as yours. I have problem to boot if there is 8Mb unalocated space in the beginning of the drive which seems is not a problem for Terry's hardware and I guess for almost any other new hardware.

It is better just to add what we find as solution to not general problems in DebianDog documentation.

Toni

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

Re: BIOS/ATA limitations workaround found

#2258 Post by mcewanw »

saintless wrote: There is no need to make debdog-install so complicated since the problems you have on your old hardware are not the same on mine much older hardware. I even doubt someone else will use DebianDog on old hardware like mine.
I have no problem to boot 512Mb and 8Gb flash drive using debdog-install latest version.
Hi Toni, fair enough, and I wanted to test the mechanism further before even modifying my own copy of debdog-install. Turns out my original 'solution' was wrong anyway (it is complex testing these things so easy to be in error...:-) so I have removed most of the txt from my earlier post above about this (so as not to confuse anyone or give them false hope..!). I have been testing all day to try and find out what is going on.

Note that my 'old' machine turns out to have BIOS from 2003. It is a Pentium M class machine, with 1GB RAM and 1.6GHz Pentium M cpu so a class of machine of which there are many around and all capable of running DebianDog well. Of course, only some such machines will have an equally rubbish BIOS...

Here are the results in case some other user finds them useful:

1. If I use debdog-install to install debiandog onto my 'tricky' 4GB usb, the resulting install seems to ALWAYS SUCCEED when I then boot from that usb on my newer computer.

2. However, even though it will work on newer computer, I can create the installation in such a way that it will ALWAYS FAIL when I try to boot it on my older computer, which is a Fujitsu Siemens Amilo laptop, 1.6GHz CPU with 1GB Ram, whose BIOS turns out to be American Megatrends from year 2003. The boot always fails on this machine if I use debian dog gparted (either alone or via debdog-install) to create the partitions on the usb I am installing to (but will still boot fine on my newer machines). I discovered this in further tests today.

3. I now know how I managed to get it working yesterday (it wasn't what I thought). I forgot that yesterday I had at one stage used Lubuntu fdisk and mkfs.ext4 to re-partition the usb and reformat it. I then took that Lubuntu formatted usb and, using debiandog and debdog-install made an installation. THAT INSTALLATION now booted fine also on my old machine. Further/many repeated tests today led me to realise that the Lubuntu fdisk was somehow adjusting the CHS values automatically such that the no. of heads was displayed as less than 16 after the partition for the installation had been made.

4. I thus tried to use fdisk and mkfs.ext4 on debiandog instead (having first used gparted to make an installation that wouldn't boot on my old machine. However, unlike on Lubuntu, debiandog's fdisk wasn't automatically changing the CHS values automatically. I thus used debiandog's fdisk in 'expert' mode to force the heads to a value less than 16 as follows:

fdisk /dev/sdb
Command: d to delete all the partitions (only was one).
Command: x to enter expert mode.
Command: h to adjust apparent number of heads to 2 (anything under 16 seemed to do the job actually).
Command: r to return to normal menu
Command: n to create a new partition 1 spanning the whole usb. Note that I repeated this experiment with start 2048 sectors (1MiB) and 16384 sectors (8MiB)
Command: w to write the new partition info to the usb and quit fdisk.

EDIT: Note that above can be done from single commandline command using sfdisk commandline options. You can find method in follow-up post below here: http://www.murga-linux.com/puppy/viewto ... 198#770198

5. Running debdog-install with this already partitioned usb, I chose gparted, but ONLY to format the /dev/sdb1 partition (using ext4) - I repeated the experiment using mkfs.ext4 -O ^has_journal on another occasion with the same good results.

6. I then in debdog-install selected Directory 'DebianDog Folder' as /mnt/home/live and pressed install button to copy that to the /dev/sdb1 ext4 partition.

The resulting debiandog usb installation now boots on both my old machine and newer machines. Like I say, I have repeated this experiment many times, first using gparted to partition (which always created an installation that WILL NOT boot on my older machine, but will boot on my newer machine) and then using debdog fdisk in expert mode to change heads to 2 (from whatever they originally were). Sometimes, I used a starting offset of 1 MiB and sometimes 8MiB in fdisk creation of partition - on my machine that made no difference - just the number of heads mattered... Note that I didn't bother changing number of sectors or cylinders using fdisk in that expert mode - just the heads; I left fdisk to decide the sectors and cylinders it liked, and that worked fine.

Though you say your machine won't boot usb with 8MiB offset Toni (and that may well be the case), I would still be grateful if you could try the above method with 8MiB offset just to be sure gparted isn't the culprit really. At least now I don't need to use Lubuntu to fix the usb CHS values, though I don't know why the Lubuntu fdisk is cleverer than the debiandog one (since Lubuntu fdisk automatically adjusted no. of heads to <16 on creating the new partition on this 4GB usb stick).

WOW, that was a lot to write, and maybe makes no sense to anyone else, but it really worked on my old banger machine and repeatably this time (and repeatedly failed if used gparted to partition interestingly enough - but remember - ALWAYS booted fine on newer machine anyway - its just my older machine needed to avoid debiandog gparted for partitioning and needed fdisk to adjust head count value).

Must have installed 100 times today in all these tests! NOTE WELL, that I didn't need to copy vmlinux first afterall; apart from using fdisk as described (and not gparted to partition) the actual installation was just the standard debdog-install one.

EDIT: For some completeness I should mention again that my old Amilo laptop won't itself actually boot from usb (meaning no such option in its BIOS). Instead I have the 'wee' bootloader (grub4dos variant) installed in MBR of Amilo's harddrive and grldr and menu.lst on first partition of same hardrive, which is used to boot vmlinuz1, initrd1.xz, and all the other bits and pieces from the usb where live folder is.
Last edited by mcewanw on Wed 09 Apr 2014, 09:46, edited 3 times in total.
github mcewanw

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#2259 Post by fredx181 »

William wrote:However, unlike on Lubuntu, debiandog's fdisk wasn't automatically changing the CHS values automatically.
I wonder where the fdisk included in DebianDog comes from.
Officially it's part of the gnu-fdisk package but it's not installed.
Looking at the size of fdisk from gnu-fdisk (extracted the .deb) it's different from the included one.

Fred

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#2260 Post by mcewanw »

fredx181 wrote:
William wrote:However, unlike on Lubuntu, debiandog's fdisk wasn't automatically changing the CHS values automatically.
I wonder where the fdisk included in DebianDog comes from.
Officially it's part of the gnu-fdisk package but it's not installed.
Looking at the size of fdisk from gnu-fdisk (extracted the .deb) it's different from the included one.

Fred
Maybe I should try with gnu-fdisk package installed then in case gparted partitioning problem somehow stems from that?

EDIT: Fred, gnu-fdisk seems to be different from standard fdisk. From apt-cache show gnu-fdisk
Description-en: Linux fdisk replacement based on libparted
GNU fdisk is a replacement to the old Linux fdisk. It provides the same
features as the original fdisk provides plus some interesting ones like:
* partition resizing
* creating filesystem on newly created partitions
* partition integrity checking
* copying/moving partition
Don't think standard fdisk can create filesystems etc

EDIT2: well, just installed/tried gnu-fdisk - seems pretty much like standard fdisk to me, but it is certainly a different one. However the one in Lubuntu is more like the one in standard debiandog install, so think the debiandog existing fdisk is probably correct one (just don't know why Lubuntu fixed heads in a way that my install worked correctly on old system)
Last edited by mcewanw on Wed 09 Apr 2014, 07:23, edited 1 time in total.
github mcewanw

Post Reply